An Access Network Discovery and Selection Function (ANDSF) is disclosed in 3GPP TS 23.402 V12.6.0, TS 24.302 V12.6.0 and TS 24.312 V12.6.1, and is in charge of instructing a user equipment (UE) on policies to select one access network or another. To this end, a so-called S14 reference point is defined between an ANDSF server and an ANDSF client, which resides in the UE, so that the ANDSF server can push ANDSF rules that the UE should enforce, or the UE can pull those ANDSF rules from the ANDSF server. The standardized architecture assumes that an ANDSF client runs in the UE in order to communicate with an ANDSF server, as illustrated in FIG. 1.
The ANDSF rules are sorted by priority. Each ANDSF rule indicates one more access networks, which may also be sorted by priority and which the UE should try to connect to at a given time.
Typically, a UE is provisioned with ANDSF rules indicating that the UE should have a higher priority to connect to one or more Wireless Land Access Networks, and a lower priority to connect to the cellular network. For example, as illustrated in FIG. 5, a UE with an ANDSF client may be located in an area covered by both a cellular network and a WLAN and, by applying the ANDSF rules, such UE will try first to connect to WLAN. While this type of policies works well when the UE is mostly stationary, they create some undesired side effects when the UE is moving.
For example, as illustrated in FIG. 6 and further discussed, while a train is moving, a UE located in that train is connected with a cellular network and is enabled to use both data and voice services. When the train approaches and stops in a railway station covered by a Wireless Land Access Network (WLAN), as illustrated in FIG. 7, the UE detects such WLAN, due to preloaded ANDSF rules, the UE applies such ANDSF rules prioritizing the WLAN, and connects to the WLAN.
For a UE getting off the train and staying in the area covered by the WLAN, as illustrated in FIG. 7, these ANDSF rules and the achieved behaviour are considered correct, because the UE has WLAN connectivity for a reasonably long time, and the operator indicated that the WLAN has a higher priority than the cellular network. Therefore, this is considered to be a desirable handover.
However, for a UE staying onboard the train and moving toward a next station, as also illustrated in FIG. 7, these ANDSF rules would force the UE to handover from the cellular network to WLAN, while the train is stopped, and to immediately switch back again to the cellular network, as soon as getting out of the WLAN coverage area. These two successive switches, from cellular network to WLAN and from WLAN to cellular network, creates quite a lot of signaling in the network (attach, registration, IP address acquisition), likely a change of IP address, service interruption, battery consumption etc., and for a short period of time. Therefore, this behaviour is considered to be an unnecessary handover.
In other words, in some scenarios, successive handovers between access networks, occurring in a short period of time, should be prevented.
An apparently simple solution to the problem could be to reverse the order of priorities in the ANDSF rules that are loaded to the UE, so that the WLAN has lower priority than the cellular network. However, this apparent solution has the side effect of preventing the UE from ever connecting to the WLAN, because the coverage of cellular networks is mostly ubiquitous, and the ANDSF client will maintain the UE connected to the highest priority network (cellular). So, this is actually not a feasible solution.
The international publication WO2011160682 addresses the issue of a UE approaching an area for which only coverage of a single access network exists (e.g. a tunnel). In this scenario, it is desired to switch to the only existing access network as soon as possible, even prior to the UE entering the tunnel.
WO2011160682 provides for a solution whereby the ANDSF computes a location and trajectory of the UE, so that the ANDSF can predict the tunnel entry, detect the area of single radio coverage, and push policies in advance to affected users, so that the UE can switch to the only existing access network.
Whilst both WO2011160682 and the present specification address a scenario in which the UE is moving along a trajectory that is relatively easy to predict (e.g., highways, railway tracks, etc.), both address a different problem: the trajectory followed by the UE in WO2011160682 leads to an area of single radio coverage, and the trajectory followed by the UE in the present specification leads to an area with more than one radio coverage, where there is a need to select one radio coverage for some UEs and the other one for some other UEs.
Thus, the solution disclosed in WO2011160682, where there is an area approaching with only one radio coverage, cannot be applied in the present case, i.e. when approaching an area with more than one radio coverage, to select one or another for each UE.